突发：微软 Exchange 爆出 0day 漏洞，来看 POC 和技术细节
编译：代码卫士团队
微软Exchange似乎易受权限提升攻击影响，任何用户，只要有邮箱，就能变身为Domain Admin。
荷兰Fox-IT公司研究员Dirk-jan Mollema在博客上发布了PoC，并详细解释了攻击细节。Mollema认为，主要的问题在于，Exchange默认在活动目录域名具有高权限。
他在博客文章中指出，“ExchangeWindowsPermissions组在活动目录的 Domain 对象上具有WriteDacl访问权限，使得该组成员均可修改域名权限，其中的一个权限是执行DCSync操作。”
这就导致攻击者能够通过Domain Controller操作同步活动目录用户的哈希密码。攻击者可通过访问这些哈希密码假冒用户并在使用NTLM（微软的认证协议）或该域名内的Kerberos认证的服务进行认证。
目前，Mollema尚未回应相关问题。他发布的博客文章题目是《滥用Exchange：你距离成为Domain Admin仅差一个API调用》。全文如下：
在多数使用活动目录和Exchange的组织机构中，Exchange服务器都具有一种高权限：成为Exchange服务器上的Administer就足以提升至Domain Admin。最近我在ZDI上偶然发现了一篇博客文章（见文末链接），他们详细说明了如何使用NTLM经由HTTP让Exchange进行认证。结合使用NTLM中继攻击，任何人只要拥有一个邮箱就能提升至Domain Admin权限，在我所知道的大概90%的使用Exchange组织机构中都是可行的。这种攻击可能是默认的，目前尚未有任何补丁，不过可以使用一些缓解措施来阻止此类权限提升问题。本文详细说明了这种攻击，而且PoC已发布，名为“PrivExchange”。
结合利用已知漏洞的新方法
这篇文章讲的是如何结合利用一些新漏洞以及已知的协议弱点，发动新攻击。结合使用3个组件，拥有邮箱的任何用户就能提升至Domain Admin访问权限：
Exchange Servers默认的权限太高
NTLM认证易受中继攻击
Exchange的某个功能使其能够认证到具有Exchange服务器计算机账户的攻击者
Exchange和高权限
这里说的主要漏洞是，Exchange在活动目录域名中具有高权限。Exchange Windows Permissions组在活动目录的Domain对象中具有WriteDacl访问权限，导致该组的任何成员都能修改域名权限，其中一种权限是执行DCSync操作。任何具有这种权限的用户或计算机都能执行同步操作，而这种操作正常情况下是供Domain Controllers进行复制，这就导致攻击者能够同步活动目录中的所有用户的哈希密码。多名研究人员曾对此进行过阐述（见文末参考部分），而且我和同事Rindert也在去年写过。在那篇文章中我也发布了ntlmrelayx的更新，增加了在NTLM中继过程中执行这些访问控制清单(ACL)攻击的可能性。
NTLM 中继机器账户
NTLM中继已经存在有段时间了。之前，它的主要关注点是经由SMB中继NTLM，以便在其它主机上执行代码。虽然到目前为止，仍然很可能在很多未启用SMB签名进行安全加固的公司中实施这种攻击，但其它协议也易受中继攻击。我认为其中最有意思的协议就是LDAP，它可用于读取并修改活动目录中的对象。简单说一下NTLM中继，就是除非已经应用了缓解措施，否则在连接至攻击者机器上之后和网络中的其它机器进行连接时，很可能会绕过Windows自动执行的认证，如下图所示：
当认证被中继到LDAP时，目录中的对象可被修改，给予攻击者权限，包括DCSync操作所需要的权限。因此，如果我们能够使Exchange通过NTLM认证和我们进行认证，那么我们就能执行ACL攻击。值得注意的是，只有在受害者通过HTTP而非SMB和我们进行认证时，中继到LDAP才奏效。
使 Exchange 进行认证
目前为止，唯一一个缺失的组件是使Exchange认证到我们的一种简单方法。ZDI的一名未透露姓名的研究员发现，使 Exchange 经由 Exchange PushSubscription功能通过 HTTP 向任意 URL 认证是很可能实现的。他们使用这个漏洞将NTLM认证中继回Exchange（即反射型攻击）并假冒其他用户。如果我们再结合Exchange默认具有的高权限并执行中继攻击而非反射型攻击，那么我们就能使用这些权限获得DCSync权限。这个推送通知服务允许用户在即使未发生任何事件的情况下每隔X分钟（X值由攻击者设定）发送一次信息。这就能确保Exchange即使在收件箱中没有任何活动的情况下和我们连接。
执行权限提升攻击
实施攻击，实现权限提升的流程如下图所示：
我们需要使用两款工具执行该攻击：privexchange.py和ntlmrelayx。这两款工具可从GitHub的PrivExchange和impacket库中获取。以中继模式启动ntlmrelayx，以Domain Controller上的LDAP作为目标，并通过如下代码使受攻击者控制的用户提升权限（这个案例中是ntu用户）：
我们开始运行privexchange.py脚本：
如果是以没有邮箱的用户运行的话，就会得到如上出错消息。再尝试一下通过具有关联邮箱的用户运行一下：
一分钟之后（推送通知提供的值），我们可以看到连接进入ntlmrelayx，用户获得DCSync权限：
我们确认DCSynx权限位于secretsdump位置：
凭借所有活动目录用户的哈希密码，攻击者就相当于持有一张金卡，能够假冒任何用户或使用任何用户密码哈希认证到任何接受NTLM或Kerberos域名认证的服务。
技术细节：中继到 LDAP 并签名
上文提到从SMB中继到LDAP不起作用，这也是为何说这种攻击无法通过使用最近发布的SpoolService RPC滥用等实施（它通过SMB认证）的原因。由于关于这部分的问题很多，现在统一说一下。如果你不打算详细了解NTLM认证部分，可以跳过这部分。
在SMB和HTTP中的NTLM认证的不同之处在于默认协商的标记(flag)。有问题的部分是NTLMSSP_NEGOTIATE_SIGN标记(0x00000010)，如MS-NLMP第2.2.2.5节所示。通过HTTP的NTLM认证并不会默认设置该标记，但如果是通过SMB认证，则会默认设置：
当我们将它中继到LDAP时，认证成功，但LDAP的预期是所有通过衍生自密码的会话密钥签名的信息（中继攻击中不具备）。因此它会忽视任何不具备签名的信息，从而导致攻击失败。有人可能会想，是否可以在传输过程中修改这些标记，这样就不用协商签名了。由于Windows现代版本都默认包含一个MIC（信息完整性代码）即基于所有3 NTLM信息的签名，因此对其中任何信息的修改都会导致其不合法。
那我们能删除MIC吗？可以是可以，毕竟它并非受NTLM信息保护的部分，但问题是NTLM认证(NTLMv2)中的最后一道防护措施阻止这样做：在 NTLMv2 响应的底部（该响应本身以受害者密码签名）存在一个AV_PAIR 结构MsAvFlags。当该字段的值为0x0002 时，表明客户端发送了一个具有type 3信息的MIC。
修改NTLMv2响应将导致认证失效，因此我们不能删除这个flags字段。该字段说明MIC被计算且包含，将使目标服务器验证MIC，从而验证所有的3信息都不会在传输过程中遭修改，因此我们无法删除签名标记。
我认为，这种情况仅对微软对NTLM的实现有效。实现NTLM的自定义工具很可能并不受影响，只有添加MIC和AV_PAIR标记时，导致它们易受标记修改攻击，从而导致SMB -> LDAP中继成为可能。其中一个例子就是NTLM的Java实现，它可在传输过程中遭修改绕过安全措施。
攻击无需任何凭证
上一节中，我们使用受攻陷凭证执行了攻击的第一步。如果攻击者只是位于执行网络攻击的位置，但并不具备任何凭证，那么仍然很可能触发Exchange进行认证。如果我们执行SMB到HTTP（或HTTP到HTTP）中继攻击（使用LLMNR/NBNS/mitm6欺骗），那么我们就能将位于同样网络片段中的用户认证中继到Exchange EWS并使用他们的凭证触发回调。我给出了一小段修改后的httpattack.py，你可以结合ntlmrelayx从网络角度实施攻击，而无需任何凭证（你只需要修改攻击者主机即可，因为它在文件中是硬编码的）：
缓解措施
攻击依靠多种组件才能实施。在此前的博客文章中我已经强调过多种针对NTLM中继攻击和中继到LDAP的防御措施。
适用于该攻击的最重要的缓解措施包括：
删除Exchange在Domain对象上的不必要的高权限。
启用LDAP签名以及LDAP信道绑定，分别阻止中继到LDAP和LDAPS。
阻止Exchange服务器和任意端口上的工作站进行连接。
启用IIS中Exchange端点上（并非Exchange Back End，否则会导致Exchange崩溃）的Extended Protection for Authnticaiton。它将验证NTLM认证中的信道绑定参数，它将NTLM认证关联到TLS连接中并阻止向Exchange web服务进行中继。
删除注册表项(registry key)，从而能够中继回Exchange服务器，如微软对CVE-2018-8518缓解措施的讨论。
在Exchange服务器上执行SMB签名（偏好域名中的所有其它服务器和工作站）以阻止针对SMB的跨协议中继攻击。
如果不使用EWS的push/pull订阅服务，则可以通过使用限制策略将EWSMaxSubscriptions设置为0的方式禁用。这是@gentikiwi提供的方法，我还没有测试过合法应用程序使用它们的频率，因此推荐在小范围内进行测试。
工具以及受影响版本
PoC请参见 https://github.com/dirkjanm/PrivExchange，且已在如下Exchange/Windows版本上进行了测试：
将Server2012R2 上的Exchange 2013 (CU21)中继到Server 2016 DC（都是完全修复版本）
将Server 2016上的Exchange 2016 (CU11)中继到Server 2019 DC（都是完全修复版本）
将Server 2019上的Exchange 2019中继到Server 2019 DC（感谢@gentilkiwi进行测试）
如上的Exchange服务器都是使用共享权限模式安装的（默认），但有writeup指出，RBAC拆分权限部署也很容易受到攻击（我并未亲自测试过）。
Exchange 2010 SP3似乎并未受影响。在我的实验室中，这个版本按类似于以上提及的SMB协商签名，从而打破了这种中继攻击。版本14.3.435.0以及14.3.123.4均展现出这种行为。
资源/参考
可参见如下博客文章、白皮书和研究论文了解关于此类攻击的更多信息：
1. 缓解资源
https://github.com/gdedrouas/Exchange-AD-Privesc/blob/master/DomainObject/Fix-DomainObjectDACL.ps1
https://www.blackhat.com/docs/webcast/04262018-Webcast-Toxic-Waste-Removal-by-Andy-Robbins.pdf
ACL权限提升研究
https://www.blackhat.com/docs/us-17/wednesday/us-17-Robbins-An-ACE-Up-The-Sleeve-Designing-Active-Directory-DACL-Backdoors-wp.pdf
2. NTLM中继/签名讨论
NTLM反射型攻击回顾https://github.com/SecureAuthCorp/impacket/issues/451
NTLM SMB-> LDAP中继https://github.com/SecureAuthCorp/impacket/pull/500
中继凭证林总
https://www.secureauth.com/blog/playing-relayed-credentials
3.其它参考
MS-NLMP
https://msdn.microsoft.com/en-us/library/cc236621.aspx
讨论Exchange API的ZDI文章https://www.zerodayinitiative.com/blog/2018/12/19/an-insincere-form-of-flattery-impersonating-users-on-microsoft-exchange
通过meterpreter进行NTLM远程中继，讨论如何远程通过枢纽主机进行中继https://diablohorn.com/2018/08/25/remote-ntlm-relaying-through-meterpreter-on-windows-port-445/
ACL攻击相关
https://www.slideshare.net/DirkjanMollema/aclpwn-active-directory-acl-exploitation-with-bloodhound
推荐阅读
原文链接
https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/
本文由代码卫士编译，不代表其观点，转载请注明“转自代码卫士 www.codesafe.cn”。